맨위로가기

메시지 큐

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

메시지 큐는 둘 이상의 프로세스 또는 스레드 간의 비동기 통신을 구현하는 데 사용되는 기술이다. 메시지 큐는 송신자와 수신자가 동시에 상호 작용할 필요 없이 메시지를 저장하고 전달하며, 운영 체제, 응용 소프트웨어 또는 여러 컴퓨터 시스템 간에 메시지를 전달하는 데 사용될 수 있다. 메시지 큐는 비동기 통신, 시스템 통합, 비동기 작업 처리, 이벤트 기반 시스템 및 분산 시스템 등 다양한 분야에서 활용되며, 데이터의 정합성과 안전성을 보장하기 위한 다양한 구현 방식과 표준을 가지고 있다.

더 읽어볼만한 페이지

  • 이벤트 (컴퓨팅) - 비동기 입출력
    비동기 입출력은 입출력 완료를 기다리지 않고 다른 작업을 처리하는 방식으로, 완료 시 콜백이나 시그널을 통해 결과를 알려주어 효율적인 자원 활용과 성능 향상을 가져다준다.
  • 이벤트 (컴퓨팅) - 폴링 (컴퓨터 과학)
    폴링은 컴퓨터 과학에서 컴퓨터나 제어 장치가 외부 장치의 상태를 주기적으로 검사하는 방식으로, 인터럽트 방식에 비해 CPU 사용량이 높을 수 있지만 단순한 시스템에서 효과적이다.
  • 병행 컴퓨팅 - 슈퍼컴퓨터
    슈퍼컴퓨터는 일반 컴퓨터보다 훨씬 높은 성능을 가진 컴퓨터로, 복잡한 계산과 시뮬레이션을 수행하며, 프로세서, 메모리, 스토리지, 네트워크 등으로 구성되어 병렬 처리를 통해 높은 성능을 구현하고, 군사, 기상 예측, 과학 기술 분야, 인공지능 등 다양한 분야에서 활용되고 있다.
  • 병행 컴퓨팅 - 프로세스
    프로세스는 컴퓨터에서 실행되는 프로그램의 인스턴스로, 운영 체제가 시스템 자원을 효율적으로 관리하며 멀티태스킹 환경에서 독립적인 실행 흐름을 유지한다.
  • 분산 컴퓨팅 - 클라우드 컴퓨팅
    클라우드 컴퓨팅은 인터넷을 통해 컴퓨팅 자원을 서비스 형태로 제공하는 모델로, 다양한 서비스 및 배치 모델을 가지며 비용 효율성과 확장성을 제공하지만 보안 및 의존성 문제도 존재하며 지속적으로 발전하고 있다.
  • 분산 컴퓨팅 - 그리드 컴퓨팅
    그리드 컴퓨팅은 지리적으로 분산된 컴퓨터 자원을 연결하여 가상 슈퍼컴퓨터를 구축하는 기술이며, 유휴 자원을 활용하고 과학 연구 등 다양한 분야에 활용된다.
메시지 큐

2. 역사 및 현황

(이전 출력이 비어 있으므로, 수정할 내용이 없습니다. 따라서 빈칸으로 출력합니다.)

3. 주요 특징 및 기능

메시지 큐는 비동기형 통신 프로토콜의 일종으로, 송신 측과 수신 측이 동시에 메시지 큐에 데이터를 주고받을 필요가 없는 방식이다. 큐에 저장된 메시지는 수신 측이 가져갈 때까지 보관된다.[11][12][13] 메시지 큐는 대개 하나의 메시지 크기나 보존할 수 있는 메시지 수에 상한을 둔다.

메시지 큐는 운영 체제나 애플리케이션 소프트웨어 내에 구현되기도 하고, 여러 컴퓨터 간 메시지 교환이나 여러 애플리케이션 및 운영 체제 간 연결에 사용되기도 한다.[14] 이러한 메시지 큐 시스템은 시스템 장애 시에도 메시지를 보존하는 복원력 기능을 제공하는 경우가 많다.

메시지 큐의 상용 구현으로는 IBM의 WebSphere MQ, 오라클의 Oracle Advanced Queuing|오라클 어드밴스드 큐잉영어 (AQ) 등이 있다. Java 관련 표준으로는 Java Message Service가 있으며, 오픈 소스와 프로프리에터리를 포함한 여러 구현이 존재한다.

VxWorks나 QNX와 같은 실시간 운영 체제 (RTOS)에서는 메시지 큐가 주요 프로세스 간 통신 및 스레드 간 통신 기구로 사용된다.

3. 1. 비동기 통신

메시지 큐는 둘 이상의 프로세스/스레드 간에 비동기 통신 패턴을 구현하며, 이로 인해 송신자와 수신자는 동시에 메시지 큐와 상호 작용할 필요가 없다.[2] 큐에 배치된 메시지는 수신자가 검색할 때까지 저장된다.[2] 메시지 큐는 단일 메시지로 전송될 수 있는 데이터 크기와 큐에 남아 있을 수 있는 메시지 수에 대해 암시적 또는 명시적 제한을 갖는다.[2]

널리 사용되는 많은 통신 프로토콜은 동기 방식으로 작동한다. 월드 와이드 웹 및 웹 서비스에서 사용되는 HTTP 프로토콜은 사용자가 웹 페이지에 대한 요청을 보내고 응답을 기다리는 명백한 예시를 제공한다.

그러나 동기적 동작이 적절하지 않은 시나리오가 존재한다. 예를 들어, AJAX (비동기 자바스크립트 및 XML)를 사용하여 텍스트, JSON 또는 XML 메시지를 비동기적으로 보내 웹 페이지의 일부를 보다 관련성 있는 정보로 업데이트할 수 있다. 구글(Google)은 사용자가 부분적으로 입력한 쿼리를 구글의 서버로 보내고 사용자가 입력하는 과정에서 관심 있을 만한 전체 쿼리 목록을 반환하는 검색 기능인 구글 자동 완성에 이 방식을 사용한다. 이 목록은 사용자가 입력할 때 비동기적으로 업데이트된다.

다른 비동기 예시는 이벤트 알림 시스템과 게시/구독 시스템에 존재한다.

  • 애플리케이션은 다른 애플리케이션에 이벤트가 발생했음을 알릴 필요가 있지만 응답을 기다릴 필요는 없다.
  • 게시/구독 시스템에서 애플리케이션은 여러 클라이언트가 읽을 수 있도록 정보를 "게시"한다.


위의 두 가지 예에서 수신자 중 하나가 충돌한 경우 정보 발신자가 기다려야 하는 것은 의미가 없다.

애플리케이션이 반드시 동기적이거나 비동기적일 필요는 없다. 대화형 애플리케이션은 요청의 특정 부분에 즉시 응답해야 할 수 있지만 (예: 고객에게 판매 요청이 수락되었음을 알리고 재고를 사용할 약속을 처리), 다른 부분(예: 청구 계산 완료, 중앙 회계 시스템으로 데이터 전달, 다른 모든 종류의 서비스 호출)을 나중에 수행하도록 대기열에 넣을 수 있다.

이러한 모든 상황에서 메시지 큐잉을 수행하는 하위 시스템(또는 대체적으로 브로드캐스트 메시징 시스템)이 있으면 전체 시스템의 동작을 개선하는 데 도움이 될 수 있다. 메시지 큐는 비동기형 통신 프로토콜의 일종을 제공하며, 송신 측과 수신 측이 메시지 큐에 동시에 주고받을 필요가 없음을 의미한다. 큐에 놓인 메시지는 수신 측이 가져갈 때까지 저장된다. 메시지 큐는 대개 저장할 수 있는 하나의 메시지 크기나 보존할 수 있는 메시지 수에 상한을 둔다.

3. 2. 메시지 보관 및 전달 보장

메시지 큐는 둘 이상의 프로세스/스레드 간에 비동기 통신 패턴을 구현하며, 이로 인해 송신자와 수신자는 동시에 메시지 큐와 상호 작용할 필요가 없다. 큐에 배치된 메시지는 수신자가 검색할 때까지 저장된다.[2] 메시지 큐는 단일 메시지로 전송될 수 있는 데이터 크기와 큐에 남아 있을 수 있는 메시지 수에 대해 암시적 또는 명시적 제한을 갖는다.[2]

일반적인 메시지 큐 구현에서 시스템 관리자는 메시지 큐잉 소프트웨어(큐 매니저 또는 브로커)를 설치 및 구성하며, 명명된 메시지 큐를 정의한다. 또는 메시지 큐잉 서비스에 등록한다. 그런 다음 애플리케이션은 큐에 배치된 메시지를 "수신"하는 소프트웨어 루틴을 등록한다. 두 번째 및 후속 애플리케이션은 큐에 연결하여 메시지를 전송할 수 있다. 큐 매니저 소프트웨어는 수신 애플리케이션이 연결하여 등록된 소프트웨어 루틴을 호출할 때까지 메시지를 저장한다. 그러면 수신 애플리케이션은 적절한 방식으로 메시지를 처리한다.

메시지 전달에는 다양한 옵션이 있으며, 주요 고려 사항은 다음과 같다.

  • 지속성: 메시지는 메모리에 유지되거나, 디스크에 기록되거나, DBMS에 커밋될 수 있다. (신뢰성이 필요한 경우 더 많은 리소스를 사용하는 솔루션을 나타냄).
  • 보안 정책: 어떤 애플리케이션이 이러한 메시지에 액세스할 수 있어야 하는가?
  • 메시지 삭제 정책: 큐 또는 메시지에는 "시간 제한"이 있을 수 있다.
  • 메시지 필터링: 일부 시스템은 구독자가 관심 있는 미리 지정된 기준과 일치하는 메시지만 볼 수 있도록 데이터 필터링을 지원한다.
  • 전달 정책: 메시지를 최소한 한 번 전달해야 하는지, 아니면 한 번 이상 전달하지 않아야 하는지 보장해야 하는가?
  • 라우팅 정책: 많은 큐 서버가 있는 시스템에서 어떤 서버가 메시지 또는 큐의 메시지를 수신해야 하는가?
  • 배치 정책: 메시지를 즉시 전달해야 하는가? 아니면 시스템이 잠시 기다렸다가 여러 메시지를 한 번에 전달하려고 해야 하는가?
  • 큐잉 기준: 메시지는 언제 "큐에 넣어진" 것으로 간주해야 하는가? 하나의 큐에 있을 때? 아니면 적어도 하나의 원격 큐로 전달되었을 때? 아니면 모든 큐로 전달되었을 때?
  • 수신 알림: 게시자는 일부 또는 모든 구독자가 메시지를 수신했는지 알아야 할 수 있다.


이러한 사항들은 트랜잭션 의미, 시스템 신뢰성 및 시스템 효율성에 큰 영향을 미칠 수 있다.

3. 3. 다양한 구현 방식

메시지 큐는 운영 체제나 응용 소프트웨어 내에서 내부적으로 작동하는 경우가 많으며, 이러한 큐는 해당 시스템의 목적으로만 사용된다.[3][4][5]

다른 구현 방식으로는 여러 컴퓨터 시스템 간에 메시지를 전달하여 여러 응용 프로그램과 운영 체제를 연결할 수 있다.[6] 이러한 메시지 큐 시스템은 일반적으로 시스템 오류 발생 시 메시지가 손실되지 않도록 복원력 기능을 제공한다. 이러한 종류의 메시지 큐 소프트웨어(메시지 지향 미들웨어라고도 함)의 상용 구현 예로는 IBM MQ(이전의 MQ Series) 및 Oracle Advanced Queuing(AQ)이 있다. Java Message Service라는 Java 표준이 있으며, 여기에는 여러 독점 소프트웨어 및 자유 소프트웨어 구현이 있다.

VxWorks 및 QNX와 같은 실시간 운영 체제(RTOS)는 메시지 큐를 주요 프로세스 간 또는 스레드 간 통신 메커니즘으로 사용하도록 권장한다. 이는 메시지 전달과 CPU 스케줄링 간의 통합을 초래할 수 있다. 스레드 간 통신에 메시지 큐 기반을 권장하는 상용 RTOS의 초기 예로는 VRTX와 pSOS+가 있으며, 둘 다 1980년대 초로 거슬러 올라간다. Erlang 프로그래밍 언어는 '프로세스'를 사용하여 동시성을 제공하며, 이러한 프로세스는 메시지 큐를 사용하여 비동기적으로 통신한다.

메시지 큐 소프트웨어는 독점 소프트웨어, 오픈 소스 또는 둘의 혼합일 수 있다. 이는 사설 서버 내 온-프레미스 또는 외부 클라우드 서버(메시지 큐 서비스)에서 실행된다.

  • 독점 옵션은 가장 오랜 역사를 가지고 있으며, IBM MQ와 같이 메시지 큐잉의 시작부터 존재했던 제품과 Microsoft Message Queuing (MSMQ)와 같이 특정 운영 체제에 묶여 있는 제품이 있다. 클라우드 서비스 제공업체는 또한 Amazon Simple Queue Service(SQS), StormMQ, Solace, IBM MQ와 같은 독점 솔루션을 제공한다.
  • 오픈 소스 메시징 미들웨어 시스템으로는 Apache ActiveMQ, Apache Kafka, Apache Qpid, Apache RocketMQ, Enduro/X, JBoss Messaging, JORAM, RabbitMQ, Sun Open Message Queue, Tarantool 등이 있다.


하드웨어 기반 메시징 미들웨어 공급업체의 예로는 Solace, Apigee, IBM MQ 등이 있다.

3. 4. 표준 및 프로토콜

과거에는 메시지 큐잉이 독점적이고 폐쇄적인 프로토콜을 사용했기 때문에, 서로 다른 운영 체제나 프로그래밍 언어가 이기종 환경에서 상호 작용하는 능력이 제한되었다.

메시지 큐잉을 보다 보편적으로 만들려는 초기 시도로는 썬 마이크로시스템즈의 JMS 사양이 있었다. 이는 클라이언트 API의 자바 전용 추상화를 제공했다. 이를 통해 자바 개발자는 SQL 데이터베이스를 사용하는 개발자와 유사한 방식으로 메시지 큐잉 제공자를 전환할 수 있었다. 실제로, 메시지 큐잉 기술과 시나리오의 다양성을 고려할 때, 이것이 항상 실용적이지는 않았다.

오픈 소스 메시지 큐 구현에서 사용되는 세 가지 표준이 등장했다.

  • 고급 메시지 큐잉 프로토콜(AMQP) – 기능이 풍부한 메시지 큐 프로토콜로, 2014년 4월부터 ISO/IEC 19464로 승인되었다.
  • 스트리밍 텍스트 지향 메시징 프로토콜(STOMP) – 간단한 텍스트 지향 메시지 프로토콜
  • MQTT (구 MQ 텔레메트리 전송) – 특히 임베디드 장치를 위한 경량 메시지 큐 프로토콜


이러한 프로토콜은 표준화 및 채택의 서로 다른 단계에 있다. 처음 두 개는 HTTP와 동일한 수준에서 작동하며, MQTT는 TCP/IP 수준에서 작동한다.

일부 독점적인 구현은 또한 아마존의 SQS와 같은 몇몇 구현에서 HTTP를 사용하여 메시지 큐잉을 제공한다. 이는 요청-응답 의미론을 사용하여 동기 프로토콜 위에 비동기적 동작(메시지 큐잉에 필요한 것)을 항상 계층화할 수 있기 때문이다. 그러나 이러한 구현은 이 경우 기본 프로토콜에 의해 제한되며, 위에서 메시지 전달에 필요한 전체 충실도나 옵션 집합을 제공하지 못할 수 있다.

4. 구현 방식

메시지 큐는 다양한 방식으로 구현될 수 있다. 운영 체제나 애플리케이션 소프트웨어 내에 구현되어 해당 시스템에서만 사용되는 경우가 있다.[11][12][13]

다른 구현 방식으로는, 컴퓨터 간 메시지 교환이나 여러 애플리케이션 또는 운영 체제 간 연결에 사용되는 메시지 큐 시스템이 있다.[14] 이러한 시스템은 시스템 장애 시에도 메시지를 보존하는 "회복력(resilience)" 기능을 제공하는 경우가 많다. 이러한 메시지 큐를 구현한 상용 소프트웨어(메시지 지향 미들웨어)로는 IBM의 WebSphere MQ, 오라클의 Oracle Advanced Queuing|오라클 어드밴스드 큐잉영어 (AQ), 마이크로소프트의 Microsoft Message Queuing|마이크로소프트 메시지 큐잉|label=MSMQ영어 등이 있다. Java 관련 표준으로는 Java Message Service가 있으며, 오픈 소스와 프로프리에터리 구현이 모두 존재한다.

몇 가지 오픈 소스 메시지 관련 미들웨어 시스템으로는 JBoss Messaging, JORAM, Apache ActiveMQ, Apache Qpid|아파치 큐피드영어[15], RabbitMQ, OpenMQ 등이 있다.

VxWorks나 QNX와 같은 실시간 운영 체제 (RTOS)에서는 메시지 큐가 주요 프로세스 간 통신 및 스레드 간 통신 기구로 사용된다. 이 경우, 실시간성이 중요하므로 메시지 큐와 CPU 스케줄링이 밀접하게 관련되어 있다. 1980년대 초에는 VRTX나 pSOS+와 같은 RTOS에서 메시지 큐를 사용한 스레드 간 통신 기구가 사용되기 시작했다.

4. 1. 운영체제 수준 구현

운영 체제나 응용 소프트웨어 내에서 내부적으로 작동하는 메시지 큐 구현이 많다. 이러한 큐는 해당 시스템의 목적으로만 존재한다.[3][4][5]

여러 컴퓨터 시스템 간에 메시지를 전달하여 여러 응용 프로그램과 운영 체제를 연결하는 구현도 가능하다.[6] 이러한 메시지 큐 시스템은 시스템 오류 발생 시 메시지가 손실되지 않도록 복원력 기능을 제공하는 경우가 많다. 이러한 종류의 메시지 큐 소프트웨어(메시지 지향 미들웨어)의 상용 구현 예로는 IBM MQ (이전의 MQ Series) 및 Oracle Advanced Queuing (AQ)가 있다. Java Message Service라는 Java 표준이 있으며, 여기에는 여러 독점 소프트웨어 및 자유 소프트웨어 구현이 존재한다.

VxWorks 및 QNX와 같은 실시간 운영 체제 (RTOS)는 메시지 큐를 기본 프로세스 간 또는 스레드 간 통신 메커니즘으로 사용하도록 권장한다. 이는 메시지 전달과 CPU 스케줄링 간의 통합을 초래할 수 있다. 스레드 간 통신에 메시지 큐 기반을 권장하는 상용 RTOS의 초기 예로는 VRTX와 pSOS+가 있으며, 둘 다 1980년대 초로 거슬러 올라간다. Erlang 프로그래밍 언어는 ''프로세스''를 사용하여 동시성을 제공하며, 이러한 프로세스는 메시지 큐를 사용하여 비동기적으로 통신한다.

유닉스 환경에는 두 가지 일반적인 메시지 큐 구현 방식이 있다. 하나는 SYS V API의 일부이고, 다른 하나는 POSIX의 일부이다.

유닉스 SYS V는 메시지 큐로 연결된 리스트의 배열을 유지함으로써 메시지 전달을 구현한다. 각 메시지 큐는 배열 내의 인덱스로 식별되며 고유한 디스크립터를 갖는다. 주어진 인덱스는 여러 개의 디스크립터를 가질 수 있다. 유닉스는 메시지 전달 기능에 접근하기 위한 표준 함수를 제공한다.[7]

  • `msgget()`: 이 시스템 호출은 키를 인수로 받아서 일치하는 키를 가진 큐가 존재할 경우 해당 큐의 디스크립터를 반환한다. 만약 큐가 존재하지 않고 `IPC_CREAT` 플래그가 설정되어 있다면, 주어진 키로 새로운 메시지 큐를 만들고 해당 디스크립터를 반환한다.
  • `msgrcv()`: 주어진 큐 디스크립터에서 메시지를 수신하는 데 사용된다. 호출 프로세스는 큐에 대한 읽기 권한을 가져야 한다. 두 가지 유형이 있다.[8]
  • 블로킹 수신은 요청된 메시지 유형을 찾을 수 없는 경우 자식 프로세스를 대기 상태로 만든다. 다른 메시지가 큐에 게시될 때까지 대기하며, 이후 다시 깨어나서 확인한다.
  • 논블로킹 수신은 실패했음을 언급하며 즉시 호출자에게 반환한다.
  • `msgctl()`: 소유자와 같은 메시지 큐 매개변수를 변경하는 데 사용된다. 가장 중요한 것은 `IPC_RMID` 플래그를 전달하여 메시지 큐를 삭제하는 데 사용된다. 메시지 큐는 생성자, 소유자 또는 슈퍼유저만 삭제할 수 있다.


POSIX.1-2001 메시지 큐 API는 두 가지 UNIX 메시지 큐 API 중 최신 버전이다. 이는 SYS V API와는 구별되지만 유사한 기능을 제공한다. 유닉스 매뉴얼 페이지 `mq_overview(7)`은 POSIX 메시지 큐에 대한 개요를 제공한다.

4. 2. 소프트웨어 및 서비스 구현

메시지 큐는 운영 체제나 응용 소프트웨어 내에서 내부적으로 작동하는 경우가 많다. 이러한 큐는 해당 시스템의 목적에 맞게 사용된다.[3][4][5]

여러 컴퓨터 시스템 간에 메시지를 전달하여 여러 응용 프로그램과 운영 체제를 연결하는 구현도 가능하다.[6] 이러한 메시지 큐 시스템은 시스템 오류 발생 시 메시지가 손실되지 않도록 복원력 기능을 제공하는 경우가 많다. 이러한 종류의 메시지 큐 소프트웨어(메시지 지향 미들웨어라고도 함)의 상용 구현 예로는 IBM MQ (이전의 MQ Series) 및 Oracle Advanced Queuing (AQ)가 있다. Java Message Service라는 Java 표준이 있으며, 여기에는 여러 독점 소프트웨어 및 자유 소프트웨어 구현이 존재한다.

VxWorks 및 QNX와 같은 실시간 운영 체제 (RTOS)는 메시지 큐를 기본 프로세스 간 또는 스레드 간 통신 메커니즘으로 사용한다. 이는 메시지 전달과 CPU 스케줄링 간의 통합을 가능하게 한다. 스레드 간 통신에 메시지 큐 기반을 권장하는 상용 RTOS의 초기 예로는 VRTX와 pSOS+가 있으며, 둘 다 1980년대 초부터 사용되었다. Erlang 프로그래밍 언어는 ''프로세스''를 사용하여 동시성을 제공하며, 이러한 프로세스는 메시지 큐를 사용하여 비동기적으로 통신한다.

메시지 큐 소프트웨어는 독점 소프트웨어, 오픈 소스 또는 둘의 혼합일 수 있다. 이는 사설 서버 내 온-프레미스 또는 외부 클라우드 서버(메시지 큐 서비스)에서 실행된다.

  • 독점 옵션은 오랜 역사를 가지고 있으며, IBM MQ와 같이 메시지 큐잉의 시작부터 존재했던 제품과 Microsoft Message Queuing (MSMQ)와 같이 특정 운영 체제에 묶여 있는 제품이 있다. 클라우드 서비스 제공업체는 Amazon Simple Queue Service(SQS), StormMQ, Solace, IBM MQ와 같은 독점 솔루션을 제공한다.
  • 오픈 소스 메시징 미들웨어 시스템으로는 Apache ActiveMQ, Apache Kafka, Apache Qpid, Apache RocketMQ, Enduro/X, JBoss Messaging, JORAM, RabbitMQ, Sun Open Message Queue, Tarantool 등이 있다.


하드웨어 기반 메시징 미들웨어 공급업체의 예로는 Solace, Apigee, IBM MQ 등이 있다.

5. 활용 사례

메시지 큐는 다음과 같이 다양하게 활용된다.


  • 시스템 통합 및 연동: 메시지 큐잉 소프트웨어나 서비스를 이용하여 여러 애플리케이션 간 메시지 전달을 관리한다. 메시지 전달에는 지속성, 보안, 삭제 정책, 필터링, 라우팅 등 다양한 옵션을 적용할 수 있다.[11][12][13]
  • 비동기 작업 처리: 송신 측과 수신 측이 동시에 상호작용할 필요 없이 메시지를 주고받을 수 있게 해준다. Ajax를 이용한 웹 페이지 부분 업데이트나 게시-구독 모델 시스템 등이 비동기 방식의 예시이다.
  • 이벤트 기반 시스템: 그래픽 사용자 인터페이스(GUI)에서 사용자 입력 이벤트를 처리하는 데 메시지 큐(이벤트 큐)를 사용한다.
  • 분산 시스템: 운영 체제나 애플리케이션 내에서, 또는 여러 컴퓨터나 애플리케이션 간 연결에 메시지 큐를 사용할 수 있다. Java Message Service와 같은 표준이나 오픈 소스 미들웨어를 활용할 수 있다. 실시간 운영 체제(RTOS)에서는 프로세스 간 통신 및 스레드 간 통신 메커니즘으로 사용된다.

5. 1. 시스템 통합 및 연동

일반적인 메시지 큐 구현에서 시스템 관리자는 메시지 큐잉 소프트웨어(큐 매니저 또는 브로커)를 설치하고 구성하며, 명명된 메시지 큐를 정의한다. 또는 메시지 큐잉 서비스에 등록한다.

그런 다음 애플리케이션은 큐에 배치된 메시지를 "수신"하는 소프트웨어 루틴을 등록한다.

두 번째 및 후속 애플리케이션은 큐에 연결하여 메시지를 전송할 수 있다.

큐 매니저 소프트웨어는 수신 애플리케이션이 연결하여 등록된 소프트웨어 루틴을 호출할 때까지 메시지를 저장한다. 그러면 수신 애플리케이션은 적절한 방식으로 메시지를 처리한다.

메시지 전달에는 다음과 같은 다양한 옵션이 있다.

  • 지속성: 메시지는 메모리에 유지되거나, 디스크에 기록되거나, DBMS에 커밋될 수도 있다. (신뢰성이 필요한 경우 더 많은 리소스를 사용하는 솔루션을 나타냄).
  • 보안 정책: 어떤 애플리케이션이 이러한 메시지에 액세스할 수 있어야 하는가?
  • 메시지 삭제 정책: 큐 또는 메시지에는 "시간 제한"이 있을 수 있다.
  • 메시지 필터링: 일부 시스템은 구독자가 관심 있는 미리 지정된 기준과 일치하는 메시지만 볼 수 있도록 데이터 필터링을 지원한다.
  • 전달 정책: 메시지를 최소한 한 번 전달해야 하는지, 아니면 한 번 이상 전달하지 않아야 하는지 보장해야 하는가?
  • 라우팅 정책: 많은 큐 서버가 있는 시스템에서 어떤 서버가 메시지 또는 큐의 메시지를 수신해야 하는가?
  • 배치 정책: 메시지를 즉시 전달해야 하는가? 아니면 시스템이 잠시 기다렸다가 여러 메시지를 한 번에 전달하려고 해야 하는가?
  • 큐잉 기준: 메시지는 언제 "큐에 넣어진" 것으로 간주해야 하는가? 하나의 큐에 있을 때? 아니면 적어도 하나의 원격 큐로 전달되었을 때? 아니면 모든 큐로 전달되었을 때?
  • 수신 알림: 게시자는 일부 또는 모든 구독자가 메시지를 수신했는지 알아야 할 수 있다.


이러한 모든 사항은 트랜잭션 의미, 시스템 신뢰성 및 시스템 효율성에 상당한 영향을 미칠 수 있다.

5. 2. 비동기 작업 처리

메시지 큐는 비동기형 통신 프로토콜의 일종으로, 메시지를 보내는 측과 받는 측이 동시에 메시지 큐를 주고받을 필요가 없다. 큐에 들어간 메시지는 받는 측이 가져갈 때까지 보관된다. 메시지 큐는 보통 저장할 수 있는 메시지 크기나 보관 가능한 메시지 수에 제한이 있다.[11][12][13]

메시지 큐는 운영 체제나 애플리케이션 소프트웨어 내에 구현될 수 있으며,[14] 여러 컴퓨터, 애플리케이션, 운영 체제 간의 연결에도 사용될 수 있다. 이러한 메시지 큐 시스템은 시스템 장애 시에도 메시지를 보존하는 기능을 제공하기도 한다.

많은 통신 프로토콜은 동기형이다. 월드 와이드 웹과 웹 서비스에서 사용되는 HTTP가 대표적인 예시이다. 동기 모델에서는 시스템이 다른 시스템에 연결하여 요청을 보내고 응답을 기다린다.

하지만 비동기 방식이 더 효율적인 경우도 있다. 예를 들어, AJAX (자바스크립트와 XML)는 비동기적으로 텍스트나 XML을 보내 웹 페이지의 일부를 업데이트한다. 구글은 자동 완성 기능에 이 방식을 사용하여 사용자가 검색어 일부를 입력하면 예상 검색어 목록을 보여준다.

이벤트 알림 시스템이나 게시-구독 모델 시스템도 비동기 방식의 예시이다.

  • 애플리케이션이 다른 애플리케이션에 이벤트 발생을 알리지만 응답을 기다릴 필요가 없는 경우
  • 게시-구독 모델 시스템에서 애플리케이션이 정보를 여러 수신자에게 "게시"하는 경우


애플리케이션은 동기 또는 비동기 중 한 가지 방식으로만 구현될 필요는 없다. 예를 들어, 고객에게 재고 확인 후 구매 요청 처리 완료를 알리는 것처럼 즉시 응답해야 하는 요청도 있지만, 결제 금액 계산 완료, 중앙 데이터베이스 등록 등 지연 처리할 수 있는 부분도 있다. 이러한 경우 비동기형 메시지 큐를 사용하면 시스템 전체 성능, 특히 고객이 체감하는 응답 성능을 향상시킬 수 있다.

5. 3. 이벤트 기반 시스템

그래픽 사용자 인터페이스(GUI)는 마우스 클릭, 키보드 이벤트 또는 기타 사용자 입력과 같은 그래픽 입력 동작을 응용 프로그램에 전달하기 위해 메시지 큐를 사용하며, 이는 '이벤트 큐' 또는 '입력 큐'라고도 한다.[9] GUI 응용 프로그램은 이벤트 루프에서 `getNextEvent()` 또는 유사한 루틴을 호출하여 이러한 이벤트를 한 번에 하나씩 제거한 다음, 해당 이벤트를 처리하기 위해 적절한 응용 프로그램 루틴을 호출한다.[10]

많은 통신 프로토콜은 동기형이다. 월드 와이드 웹이나 웹 서비스에서 사용되는 HTTP 등은 명백히 동기형이다. 동기 모델에서는, 어떤 시스템이 다른 시스템과의 연결을 형성하고, 요청을 보내고, 응답을 기다린다. 많은 경우, 이것으로 전혀 문제가 없다. 예를 들어, 사용자가 웹 페이지에 요청을 보내고, 응답을 기다리는 경우이다.

그러나 이러한 시나리오는 잘 되지 않는 경우가 있다. 예를 들어, AJAX(Asynchronous 자바스크립트 and XML)는 비동기적으로 텍스트나 XML을 보내, 웹 페이지의 일부를 보다 적절한 정보로 갱신한다. 구글은 자동 완성 기능으로 이 방식을 채용하고 있으며, 검색 상자에 키워드의 일부를 입력했을 때 예상되는 키워드 전체 목록을 제공한다. 이 목록은 사용자의 입력에 따라 비동기적으로 갱신된다.

다른 비동기적인 예로, 이벤트 알림 시스템이나 게시-구독 모델 시스템이 있다.

  • 어떤 애플리케이션이 다른 애플리케이션에 이벤트 발생을 알리고 싶지만, 그 응답을 기다릴 필요가 없는 (혹은 기다릴 수 없는) 경우
  • 게시-구독 모델 시스템에서는, 애플리케이션은 정보를 임의의 (알 수 없는 개수의) 수신자에게 "게시"한다.


이러한 경우, 예를 들어 정보의 수신자가 충돌했을 가능성도 있으며, 송신 측이 응답을 기다리는 것은 적절하지 않다.

애플리케이션은 동기 또는 비동기 중 한쪽만으로 구현할 필요는 없다. 대화형 애플리케이션은 특정 요청에 대해 즉시 응답할 필요가 있을 것이다 (고객에게, 재고를 확인한 후 구매 요청이 수리되었음을 알리는 경우 등). 하지만 한편으로는, 큐를 사용하여 처리를 지연시킬 수 있는 부분도 있다 (청구 금액의 계산을 완료하고, 그 데이터를 중앙 데이터베이스에 등록하고, 관련된 다른 서비스를 실행하는). 이러한 경우에, 비동기형 메시지 큐를 사용하면, 시스템 전체의 성능 (특히 고객이 볼 때의 응답 성능)을 향상시킬 수 있다.

5. 4. 분산 시스템

메시지 큐는 송신 측과 수신 측이 동시에 메시지를 주고받을 필요가 없는 비동기형 통신 프로토콜의 일종을 제공한다. 큐에 저장된 메시지는 수신 측이 가져갈 때까지 보관된다. 메시지 큐는 일반적으로 저장 가능한 메시지 크기나 보관 가능한 메시지 수에 제한이 있다.

메시지 큐는 운영 체제나 애플리케이션 소프트웨어 내에 구현될 수 있으며, 이러한 큐는 해당 시스템의 특정 용도로만 사용된다.[11][12][13]

컴퓨터 간 메시지 교환, 여러 애플리케이션 또는 운영 체제 간 연결에 사용되는 메시지 큐 시스템도 있다.[14] 이러한 시스템은 시스템 장애 발생 시에도 메시지를 보존하는 "회복력(resilience)" 기능을 제공하는 경우가 많다. 이러한 메시지 큐를 구현한 상용 소프트웨어 (메시지 지향 미들웨어)에는 IBM WebSphere MQ, 오라클 Oracle Database에 포함된 Oracle Advanced Queuing (AQ), 마이크로소프트 MSMQ, 히타치 제작소 TP1/MessageQueue, 세존 정보 시스템즈 HULFT-Message 등이 있다. Java 관련 표준으로는 Java Message Service가 있으며, 오픈 소스와 프로프리에터리를 포함한 다양한 구현이 존재한다.

메시지 관련 미들웨어 시스템 중에는 오픈 소스도 있다. 예를 들어 JBoss Messaging, JORAM, Apache ActiveMQ, Apache Qpid[15], RabbitMQ, Skytools PgQ, Mule, OpenMQ 등이 있다.

VxWorks나 QNX와 같은 실시간 운영 체제 (RTOS)에서는 메시지 큐가 주요 프로세스 간 통신 및 스레드 간 통신 메커니즘으로 사용된다. 실시간성이 중요한 경우, 메시지 큐와 CPU 스케줄링은 밀접하게 관련된다. 1980년대 초, VRTX나 pSOS+와 같은 RTOS에서 메시지 큐를 이용한 스레드 간 통신 메커니즘이 사용되기 시작했다.

6. 동기 vs. 비동기 통신

널리 사용되는 많은 통신 프로토콜은 동기 방식으로 작동한다. 월드 와이드 웹 및 웹 서비스에서 사용되는 HTTP 프로토콜은 사용자가 웹 페이지에 대한 요청을 보내고 응답을 기다리는 명백한 예시를 제공한다.

그러나 동기적 동작이 적절하지 않은 시나리오가 존재한다. 예를 들어, AJAX(비동기 자바스크립트 및 XML)를 사용하여 텍스트, JSON 또는 XML 메시지를 비동기적으로 보내 웹 페이지의 일부를 보다 관련성 있는 정보로 업데이트할 수 있다. 구글(Google)은 사용자가 부분적으로 입력한 쿼리를 구글의 서버로 보내고 사용자가 입력하는 과정에서 관심 있을 만한 전체 쿼리 목록을 반환하는 검색 기능인 구글 자동 완성에 이 방식을 사용한다. 이 목록은 사용자가 입력할 때 비동기적으로 업데이트된다.

다른 비동기 예시는 이벤트 알림 시스템과 게시/구독 시스템에 존재한다.


  • 애플리케이션은 다른 애플리케이션에 이벤트가 발생했음을 알릴 필요가 있지만 응답을 기다릴 필요는 없다.
  • 게시/구독 시스템에서 애플리케이션은 여러 클라이언트가 읽을 수 있도록 정보를 "게시"한다.


위의 두 가지 예에서 수신자 중 하나가 충돌한 경우 정보 발신자가 기다려야 하는 것은 의미가 없다.

애플리케이션이 반드시 동기적이거나 비동기적일 필요는 없다. 대화형 애플리케이션은 요청의 특정 부분에 즉시 응답해야 할 수 있지만 (예: 고객에게 판매 요청이 수락되었음을 알리고 재고를 사용할 약속을 처리), 다른 부분(예: 청구 계산 완료, 중앙 회계 시스템으로 데이터 전달, 다른 모든 종류의 서비스 호출)을 나중에 수행하도록 대기열에 넣을 수 있다.

이러한 모든 상황에서 메시지 큐잉을 수행하는 하위 시스템(또는 대체적으로 브로드캐스트 메시징 시스템)이 있으면 전체 시스템의 동작을 개선하는 데 도움이 될 수 있다.[1]

7. (참고) 윈도우 메시지 처리

Win32 프로그램의 윈도우 프로시저는 메시지 핸들러를 통해 메시지 처리를 정의한다.

그래픽 사용자 인터페이스(GUI)는 마우스 클릭, 키보드 이벤트 또는 기타 사용자 입력과 같은 그래픽 입력 동작을 응용 프로그램에 전달하기 위해 메시지 큐를 사용하며, 이는 '이벤트 큐' 또는 '입력 큐'라고도 한다.[9] 윈도우 시스템은 타이머 틱이나 다른 스레드에서 보낸 메시지와 같은 사용자 또는 기타 이벤트를 메시지 큐에 넣는다. GUI 응용 프로그램은 이벤트 루프에서 `getNextEvent()` 또는 유사한 루틴을 호출하여 이러한 이벤트를 한 번에 하나씩 제거한 다음, 해당 이벤트를 처리하기 위해 적절한 응용 프로그램 루틴을 호출한다.[10]

참조

[1] 서적 Foundations of Scalable Systems O'Reilly Media
[2] 문서 Dive Into Queue Module In Python. http://linux.die.net[...]
[3] 웹사이트 About Messages and Message Queues http://msdn.microsof[...] Microsoft Developer Network 2010-04-21
[4] 문서 Linux and POSIX message queues http://linux.die.net[...]
[5] 문서 Using Linux Message Queues http://www.civilized[...]
[6] 웹사이트 Message Queuing (MSMQ) http://msdn.microsof[...] Microsoft Developer Network 2009-05-09
[7] 서적 The Design of the UNIX Operating System https://archive.org/[...] Prentice-Hall
[8] 서적 Operating Systems Concepts Addison-Wesley
[9] 웹사이트 GUI Programming https://www.cs.rice.[...] 2020-06-27
[10] 서적 Game Programming Patterns https://gameprogramm[...] Genever Benning 2014-01-01
[11] 웹사이트 About Messages and Message Queues http://msdn.microsof[...] Microsoft Developer Network 2010-04-21
[12] 문서 Linux and POSIX message queues http://linux.die.net[...]
[13] 문서 Using Linux Message Queues http://www.civilized[...]
[14] 웹사이트 Message Queuing (MSMQ) http://msdn.microsof[...] Microsoft Developer Network 2009-05-09
[15] 문서 Apache Qpid Project, an implementation of AMQP http://qpid.apache.o[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com